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Calendar Navigation in FileMaker Pro 


by Steve Murray 
Advanced Database Systems 

FileMaker Pro provides a powerful and versatile 
assortment of Calendar functions. When combined 
with other field calculations and scripting maneu¬ 
vers, you can accomplish almost any task that in¬ 
volves date sensitive data. The rules of the Calendar 
are based on a mind-numbing set of criteria relating 
to religion, planetary cycles, the Roman Empire, 
and anglo history. Fortunately, FileMaker has taken 
care of all that by providing the necessary automa¬ 
tion for most date calculations. 

Actually, there is a “strange math” that can be 
applied to the modern calendar using the pre¬ 
defined functions provided by FileMaker. As with 
any challenge or problem that we try to solve using 
our favorite database, the process is always the same: 
find the logic. Find both the unique character of 
each piece of data and the common thread that ties 
it all together. No need to be a math wiz; if you take 
the time to analyze (count on fingers and toes), you 


can actually begin to see that the modern calendar is 
based on a recurring pattern that you can control 
and predict. 

One of the most common tasks in database 
development is to present a convenient interface for 
calendar reference and a quick and easy method for 
navigation to selected dates. Most would agree that 
clicking on a date in a monthly calendar is about as 
easy as it gets. FileMaker provides a number of ways 
to build such an interface, and all of them have pros 
and cons. Looking at the priorities of presentation, 
response time, and overall efficiency, we have found 
that the method described here provides the best 
overall performance. As a bonus, this method also 
provides a graphic indicator that highlights the 
selected date in the calendar grid display. 

Building the Calendar Navigation Tool 
Field Name Type 

1. Calendar Date Date 

Comment: 

To preserve maximum speed, we are defining 
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this as a regular date field. You may choose to 
install it as a global date field, depending on 
the planned use of the data. On current CPUs 
the difference in calendar navigation speed is 
negligible, but keep in mind that if you plan 
to use the date in numerous calculations or 
relational schemes in a large database, speed 
could become an important consideration. 

Container Fields 

To build a routine that will display a tra¬ 
ditional calendar for any selected month, we 
have two options. 

Option A: We can calculate each day, 
according to it’s position in the monthly grid. 
There are 37 possible grid positions on the 
calendar, and we would provide a calculation 
field for each one of those positions. This is 
the most common method and is especially 
useful if you plan to display the calendar in 
printed output. This option, however, re¬ 
quires 37 individual calculations that are 
triggered with each user date selection and 
can be cumbersome depending on layout 
design and other file activities. 

Option B: The method that we use in this 
example is based on the use of container 
fields. The scheme involves a single calcula¬ 


tion that will assign one of 28 possible monthly 
calendar orientations to the display container 
field. It involves more work to set up, but you 
pick up the design advantages and interface 
benefits as mentioned above. When you have 
completed this template, keep a clone for 
installation into other solutions. 

Field Name Type 

2. Calendars Global Container 

Repeating field with 28 repetitions 

Comment: 

Make your 28 calendars, and insert them 
into the 28 repetitions of the ‘Calendars’ 
global field. They should be placed into the 
repetitions in this order: the first seven calen¬ 
dars are the seven possible 31 -day months. 
The first calendar (repetition 1) with the first 
of the month occurring on Sunday, the sec¬ 
ond calendar (repetition 2) with the first of 
the month occurring on Monday and so on. 
The second seven calendars would be the 
seven possible 30-day orientations. The next 
set of seven would be the 29-day months and 
the last seven would be the 28-day months. 
(February is a pain, isn’t it?) 

You can make each calendar while in 
layout mode and then cut and paste into the 


Field Name 

Type 

Calculation 

1. Calendar Date 

Date 


2. Calendars 

Global (container) 

3. DayBox 

Global (container) 

4. Cal Month 

Calc (number) 

Month (Calendar Date) 

5. Cal Year 

Calc (number) 

Year (Calendar Date) 

6. Start Factor 

Calc (number) 

DayofWeek (Date(Cal Month,1,Cal Year))-1 

7. Month End 

Calc (number) 

Case (Cal Month=4,30,Cal Month = 6,30, 

Cal Month = 9,30,Cal Month = 11,30,Cal Month = 2, 

Case(Cal Year/4 = lnt(Cal Year/4),29,28),31) 

8.Cal Repetition # 

Calc (number) 

DayofWeek(Date(Cal Month, 1,Cal Year)) + ((31- End) * 7) 

9.DayBox Repetition # 

Calc (number) 

(Day(Cal Date)-1) + (DayofWeek(Date(Cal Month,1,CalYear))) 

10.Calendar Display 

Calc (container) 

GetRepetition(Calendars,Cal Repetition #) 

11.DayBox Display 

Calc (container) 

GetRepetition(DayBox,DayBox Repetition #) 
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correct repetition in Calendars. Make a tem¬ 
porary grid to serve as a template and you can 
quickly build each calendar. If you are work¬ 
ing on a Macintosh and the file is destined for 
a Windows platform, you may want to move 
the calendar to an outside graphics program 
before placing it in the container field, to 
insure proper appearance of numbers in the 
calendar. 

Field Name Type 

3. DayBox Global (Container) 

Repeating field with 37 repetitions 

Comment: 

This field holds the highlight or box that 
indicates the selected date. Using your tem¬ 
plate as a guide, place a rectangle over the 
outer boundaries of your calendar (Line tool: 
black, Fill: transparent). Next create a high¬ 
light box. (Line tool: 2 point red or desired 
color, Fill: transparent) It should be the exact 
size of the daily grid space. Place the red box 
over grid position #1. Select the red box and 
the outside rectangle, copy and paste into 
repetition 1 of DayBox. Repeat for positions 
2 through 37. 

Calculation Fields 

The following are all calculation fields. 
Some of them could be combined into the 
main calculations if desired. Some values are 
split into separate fields to illustrate the meth¬ 
ods and to enhance speed with stored values 
that may not have to repeat with every date 
change. 

Layout Assembly 

DayBox Display is the field that you use 
on your layout that will display the appropri¬ 
ate monthly calendar according to the select¬ 
ed date. Determine the size of your calendar, 
and size the field to the same dimensions. If 
you decide to include actual grid lines in your 


calendar, place them on top of the calendar at 
this time. The DayBox Display field contains 
the correct highlight position for the selected 
day. Make this field the exact size of the cal¬ 
endar and position on top of the Calendar 
Display field and your grid lines. Group the 
elements and place them into the graphic you 
have designed to hold the calendar. Format 
the container fields to disable (uncheck) the 
“Allow user entry into field” option. 

Date Navigation Scripts & Buttons 

It is now time to install 37 scripts, one for 
each day position. Each script is assigned to a 
transparent button positioned over the ap¬ 
propriate grid space. When the user clicks on 
a the selected day, the Calendar Date field 
will be set with the correct date value. This 
will trigger the calculations for positioning of 
the highlight. The Calendar Date field will 
also serve as the user-selected date for rela¬ 
tional links, entry, or report generation. 

The scripts for day positions 1 through 6 
and 29 through 37 start with an If step that 
checks for a valid date. The scripts for posi¬ 
tions 7 through 28 do not contain the validity 
check as they always contain a valid date. The 
Go To Field[] step inserted before Set Field 
makes sure that any date-sensitive user en¬ 
tries are properly recorded. 

Script Name: Date 1 

If ["1 - Start Factor <0 U ] 

Halt Script 
End If 

Go To Field[] 

Set Field ["Calendar Date","Date (Cal Month, 

1-Start Factor, Cal Year)"] 

Also write scripts for Date 2, Date 3 and 
so on to Date 6, by duplicating the script 
above and replacing the number value 1 in 
the If statement and the value 1 in the Set 
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Field calculation with the next number in 
sequence, (example: The Date 2 script would 
be the same as above with the If statement as 
[2-Start Factor <0] and the Set Field calcula¬ 
tion as [Date(CaI Month, 2-Start Factor, 

Cal Year)]. 

Script Name: Date 7 

Go To Field!] 

Set Field ["Calendar Date",. 

"Date(Cal Month, 7-Start Factor, Cal Year)"] 

Also write scripts for Date 8, Date 9 and 
so on to Date 28, by duplicating the script 
above and replacing the number value 7 in 
the Set Field calculation with the next num¬ 
ber in sequence, (example: The Date 8 script 
would be the same as above with the Set Field 
calculation, Date(Cal Month, 8-Start Fac¬ 
tor, Cal Year) 

Script Name: Date 29 

If ["Month(Date(Cal Month,29-Start,Cal Year)) 

*■ Cal Month”] 

Halt Script 
End If 

Go To Field!] 

Set Field ["Calendar Date", 

"Date (Cal Month, 29-Start Factor,Cal Year)"] 

Also write scripts for Date 30, Date 31 
and so on to Date 37, by duplicating the 
script above and replacing the number value 
29 in the If statement and the value 29 in the 
Set Field calculation with the next number in 
sequence, (example: The Date 30 script 
would be the same as above with the If state¬ 
ment as [“Month(Date(Cal Month,30- 
S tart,Cal Year)) ^ Cal Month”] and the Set 
Field calculation as [Date(Cal Month, 30- 
Start Factor, Cal Year)] 

Month Navigation Scripts & Buttons 

You will also need to provide navigation 


buttons (i.e. arrow buttons) that will change 
the Calendar Display field to the next or 
previous month in sequence. 

Script Name: Next Month 
Go To Field!] 

Set Field ["Calendar Date", 

"Date(Cal Month + 1,1,Cal Year)"] 

Script Name: Previous Month 
Go To Field[] 

Set Field ["Calendar Date", 

"Date(Cal Month -1,1,Cal Year)"] 

You’re done! A complete Calendar Navi¬ 
gation Tool, adaptable to almost any File- 
maker solution where date navigation is 
required. Of course, if all this seems like a 
little much to take in, you can always refer to 
our special Calendar Navigation Demo and 
Tutorial which can be downloaded from our 
web site at www.database-systems.com. The 
demo file illustrates all of the methods de¬ 
scribed above. You can also use the demo as 
your starting template, by first stripping out 
the tutorial layouts. The file also contains 
pre-built graphic elements to display the 
Calendar tool. Just drop it into your layout 
and you’re ready to go. 

Steve Murray is one of the project managers at 
Advanced Database Systems and is responsible 
for management of several lead programmers 
doing custom database systems for an array of 
clients world-wide. Advanced Database Systems 
provides several DEMO solutions to help the 
FileMaker community, which can be 
downloaded from their web site at 
www.database-systems.com 
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ThreePointOh, We Hardly Know Ye (Part 2) 


in the last issue, Part 1 of this article looked 
at a surprising and radical use of FileMaker 
3.0’s relations and global fields — buttons, 
backgrounds and other layout objects as 
related global fields. In Part 2 we use the same 
features to provide an alternative to File¬ 
Maker’s built-in Find function. 

When FileMaker first appeared, finds in 
databases were usually done on specially- 
designed find screens quite different from the 
data entry screens where records were 
browsed and edited. Only fields which had 
been specifically selected to be indexed ap¬ 
peared in these finds. The designers of File¬ 
Maker decided it was friendlier — even if it 
produced larger files — to simply index all 
fields and automatic indexing of fields be¬ 
came, until version 3.0, a defining feature of 
FileMaker. Indexing all fields allowed File¬ 
Maker Browse and Find screens to be one 
and the same. This eliminated a lot of extra 

Figure 1 



PersonChooser 


GREAT BRITAIN 2089? 
San Jose, C A 41018 
Concord CA 52058 
BigSur.CA 31850 


Huseyine, Bob 
Huseby. Ben 
Husebuy. Mike 
Husemaa Ann 




last First or Matter Number 


modify 

person 

record 


Cancel 


New Person 


set up work (which was confusing to begin¬ 
ning users) and provided an essentially un¬ 
limited variety of Find requests from 
standard data entry layouts. 

There were still some unfriendly aspects 
to FileMaker finding. Partly, there were the 
usual general limitations of computers — the 
need to be letter perfect in specifying the 
search string for instance. Also, FileMaker 
had it’s own limitations — the most annoying 
of which was an ungraceful reaction to locat¬ 
ing no records matching the Find request. 

In issue #64, this newsletter showed one 
way of ameliorating the literal fussiness of a 
Find and Claris added wild card characters 
which also helped a great deal. Version 3.0 
includes script steps which developers can 
use to ease users around and out of awkward 
Find failures and also allows an empty found 
set without facing the user with a cryptic 
dialog box. With relations it is possible to 
create new Finding layouts which are faster 
and more accurate for some kinds of com¬ 
mon searches. Using relations to enlarge the 
tool kit of Finding techniques is the subject of 
this article. 

A Search Engine 

FileMaker’s standard Find feature, used 
with something like an address data entry 
layout, is probably optimal for complex, 
arbitrary Finds. You need to see all the possi¬ 
ble fields which might be used in the Find 
and, with a little practice, most users can 
learn to specify complicated finds which 
include multiple fields (a logical AND), mul¬ 
tiple requests (logical OR) and omits (logical 
NOR). 

Yet, for the simple and common task of 
locating a single record, like a customer name 
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and address or a product, FileMaker’s built- 
in Find can stand improvement. It is too easy 
to miss an existing record when the Find 
request, say of a person’s last name, is slightly 
misspelled. Or, the Find request spelling 
might be correct and the existing record have 
a mistaken entry. Of course, the operator can 
do repeated searches using alternate spellings 
but that takes time and success is far from 
certain. 

Instead, we can use version 3.0’s relation¬ 
al portals to enhance a single-record Find. 
Figure I shows a search layout for finding 
person records in a database for a conference 
center. In this case, a small file is dedicated 
entirely to doing these kinds of searches. The 
advantage of putting the search engine in a 
separate file is that it becomes easy to use the 
search file from any other file in the database. 
For instance, you might want to find a person 
record, or capture a customer ID number, 
not only to edit an address but also to create 
an invoice or pur¬ 
chase order, make an 
appointment or res¬ 
ervation, or credit a 
payment. By placing 
basic scripts (like a 
script to grab a per¬ 
son record ID num¬ 
ber) in the search file, 
any external script 
can call these basic 
search file scripts and 
use the resulting 
information in what¬ 
ever way is appropri¬ 
ate. This subscripting 
technique also makes 
the search file easily 
portable from one 
database to another. 



Figure 2 


Figure 3 
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Define Fields for “PersonChooser” 


Field Name 


$ CurrentUser 


♦ SeerchCriteriaText 

♦ SearchCriteriaCalc 

♦ GlobalConstant 

♦ BypassPerson 

♦ OpenStatus 


6 field(s) 


I'JP-i 

Global 

Calculation 

Global 

Global 

Global 


O ptions 


View by | custom order ▼ 


Text 

Unstored, = IT(TextToNum(SearchCriteriaText)>1 ,Seatj 
Text 
Text 
Text 


Figure 4 The Basic Relationship 

Figure 2 shows the search file in layout 
mode. The portal, defined by the relation 
“Search Key”, shows fields from a person file 
which are helpful in identifying the right 
address record during a search. The relation 
is shown in Figure 3. 

The search file requires only a few fields 
and the home key is the only calculation field 
(see Figure 4): 

SearchCriteriaCalc = 
lf(TextToNum(SearchCriteriaText) > 1, 
SearchCriteriaText, 

Left(LeftWords(SearchCriteriaText, 1 ),8) 

& lf(MiddleWords(SearchCriteriaText,2,1) > 0, 

& Left(MiddleWords(SearchCriteriaText,2,1 ),1), 
"") & "H") 

This calculation is broken up into multi¬ 
ple lines (allowed by a feature of version 3.0) 
to make it easier to understand and change. 
The first line tests to see if the search criteria 
entered by the user is a number. If it is, this 
number becomes the search file home key. 
This has been done so that users can search 
by either the name or person ID number, if 
they have it. If a name is entered instead of an 
ID number, the second line grabs up to the 
first eight characters of the last name, which is 
always entered first by the user. The third 
calculation line tests to see if more than one 
word is being searched for and, if so, it adds a 
space and the first letter of the first name. 

There are limitations to this scheme. First 
the search assumes that last names are always 


one word. Users have 
to be trained to enter 
“de Angelo” as 
“deAngelo” regard¬ 
less of the correct 
spelling. Also, the 
search does not con¬ 
sider more than the 
first character of the 
first name. Since portal records are currently 
not sortable — in any straightforward way— 
in FileMaker, the names appear in the order 
of their creation, not alphabetically. 

Basic Searching 

The idea of the search file is to show in 
the portal a list of possible records which 
meet the search criteria. When the operator 
sees the right record, clicking on the line 
executes a script which sets a global field to 
the ID number of the selected person’s ad¬ 
dress record. The external script that called 

I 

for the search can then grab the value from 
this global field and use the person ID num¬ 
ber for whatever purposes it desires. 

Spotting the right record quickly is the 
strong point of the search file. Searching is 
always under control of one or more search 
file scripts. These scripts allow the user to 
enter only as many search characters as are 
required to get the list down to a usable size. 
After one or more characters are typed in, 
hitting the enter key refreshes the contents of 
the portal, showing a new, more restricted 
list. The script returns the cursor immediately 
to the end of the search field so that addition¬ 
al characters may be entered right away. Fig- 
| ure 1 shows a list which matches four 

characters (“Huse”). If this list happened to 
be too long, the user can add more characters 
or a space and the first name to get a shorter 
list. 
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The Foreign Key 

What sort of foreign key would have the 
suitable matches for the calculated home key 
SearchCriteriaCalc? The foreign key is a 
complex, indexed calculation field which 
must generate a match for every possible 
appropriate value in the home key. These 
matching values are separated by carriage 
returns and FileMaker relations consider that 
a match occurs when any line in the home 
key matches any line in the foreign key. So 
the formula is: 

PersonChooserkey = 

Old ID Numbers & "H" & 
hkRecordNumber & "H" & "all" & "H" & 
Substitute(LastName, "a", "") & "H" & 
Substitute(LastName, "a", "") & "a" & 
Left(FirstName,1) & "IT & 
Left(Substitute(LastName, "a", 1) & "H" & 

Left(Substitute(LastName, "a", 2) & "IT & 

Left(Substitute(LastName, "A", 3) & "H" & 
Left(Substitute(LastName, "a", 4) & 'T & 

Left(Substitute(LastName, "A",5) & "H" & 
Left(Substitute(LastName, "a", 6) & "H" & 

Left(Substitute(LastName, "a", 7) & "H" & 

Left(Substitute(LastName, "A", 8) & "H" & 
Left(Substitute(LastName, "a", 1) & "A" & 

Left(FirstName,1) & "H" & 
Left(Substitute(LastName, "a", 2) & "a" & 

Left(FirstName,1) & "H" & 
Left(Substitute(LastName, "A", 3) & "A" & 
Left(FirstName,1) & "H" & 
Left(Substitute(LastName, "a", 4) & "a" & 

Left(FirstName,1) & "H" & 
Left(Substitute(LastName, "a", 5) & "a" & 

Left(FirstName,1) & "H"& 
Left(Substitute(LastName, "a", 6) & "A" & 

Left(FirstName,1)&"H"& 
Left(Substitute(LastName, "a", 7) & "A" & 

Left(FirstName,1) & "H" & 
Left(Substitute(LastName, " A ",8) & "a- & 
Left(FirstName,l) 


The Substitute function strips all spaces 
from last names consisting of more than one 
word. The “all” value is added to every for¬ 
eign key value for the obvious requirement of 
occasional viewing of all records in the search 
portal. The number is the person ID number. 
The result of this calculation for the case of 
Figure 1 (the Ann Huseman record) is: 

31850 

all 

Huseman 
Huseman A 
H 

Hu 

Hus 

Huse 

Husem 

Husema 

Huseman 

Huseman 

HA 

Hu A 

Hus A 

Huse A 

Husem A 

Husema A 

Huseman A 

Huseman A 

Speed Demon 

Clearly, it is possible to accomplish more 
or less the same results using conventional 
FileMaker techniques, although the search 
file allows users to spot many more marginal 
matches and so results inthe creation of far 
fewer duplicate records. In fact, the conven¬ 
tional method of choosing from a list view 
layout allows records to be sorted in various 
ways to help Find the right record. The ad¬ 
vantage of the search file is speed. First, the 
user has to type into the search field only the 
number of characters necessary to show a 
usable list. More important, locating a group 
of records through a portal is much faster 
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than regular a FileMaker Find. This speed 
advantage can also be used to speed a con¬ 
ventional Find by using “Go To Related 
Records” script steps in place of conventional 
find steps. We’ll look at such tricks next issue. 


This article was written by Mike Harris. It is 
based on work by Bill Richardson of Cerne Sys¬ 
tems Inc. The original search engine file was creat¬ 
ed for Esalen Institute in BigSur California. 


A Universal “Back” Button 


By Bill Richardson j 

Browsing the World Wide Web, it is com- | 
mon to dive many levels into a hierarchy of 
links. Yet to return to a previous page, you 
simply click on the browser’s Back button. 

Each time you follow a new link, the net 
browser records the location of the current 
page before moving to the next. This list of 
pages you have browsed is called a global 
history. When you click Back the browser 
returns to the last link in the global history list 
and then deletes that link from the list. 

What does this have to do with FileMaker? 

In a typical FileMaker database some files and 
layouts are used in more than one task. A 
customer address data entry record, for in¬ 
stance, might be used in creating an invoice, 
updating an address, reviewing telephone 
call-back commitments, writing a letter and 
for several other reasons. So you can arrive at 
a given layout from many different places and 
need a suitable scripted (button) return for 
each. You may even interrupt a completely 
unrelated task to jump someplace for a quick 
record fix — and want to jump right back to 
what you were doing, or trace a unique path 
backward several steps. 

With FileMaker 3.0 global fields, relations, 
conditional scripting, and status functions, 
you can do all these things with a global his¬ 
tory engine similar to that of a web browser. | 


Among other benefits, a single universal Back 
button may substitute for the many dedicated 
buttons required to cover all possible return 
paths from a commonly used layout like an 
address data entry screen. This not only saves 
screen real estate but development time, and 
requires no consideration of whether an un¬ 
usual path justifies its own set of navigation 
scripts. 

Cumulatively, a Back button has the po¬ 
tential to save tremendous amounts of work 
and screen space while providing completely 
scripted navigation for even the most unusual 
situations. A Back button (Figure 1) also 
works well with small free-standing utility 
files such as those which might be used to 
find people or room availability in a hotel. 
These utility files can serve a very general 
function such as finding a customer ID num¬ 
ber, which is needed for scripts in many dif¬ 
ferent parts of the database. With a Back 
button (or its script equivalent) these utility 
files can be kept very simple and used pain¬ 
lessly from any file and layout. 

A FileMaker global history keeps track of 
each layout you have visited. To return to the 
previous layout, you click a button that acti¬ 
vates the Back script. The Back script returns 
to the previous layout (and file if applicable) 
while deleting that information from the 
global history. Once the engine is in place, it 
may be used for all layouts, even new ones 
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added later. While it is also 
possible to retrieve a found set 
or a specific record, this article 
considers only layout and file 
navigation. 
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Design Considerations 

In this case, the key to 
good file architecture is the 
centralized storage of a global 
history. Most FileMaker data¬ 
bases have many files and each 
needs access to global history 
fields for both writing (“to go 
forward” in this article) and 
reading (“to go back”). This 
control file can be any one of your database 
files, a general purpose utility file, or a sepa¬ 
rate file dedicated to the Back function. I 
generally use a Resources_ file in every 
project to store all common data (like ZIP 
code lookup records), images (like company 
logos), and utility functions (like this Back 
button). Since Resources_ data and func¬ 
tions are commonly used on every project, 
this file grows increasingly useful from 
project to project. 

Recording a move you want to be avail¬ 
able in a Back sequence requires that the step 
be part of a script — it is not possible to 
record moves made using FileMaker tools 
like the Layout menu. This is not usually a 
problem since buttons for routine navigation 
make sense even for users who know how to 
navigate without scripts. It is just much faster 
to use buttons and the investment in naviga¬ 
tion scripts pays off quickly in any database 
which gets regular use. We want to make it as 
easy as possible to add the Back button to 
new files. This means putting as much of the 
function as possible in the central global his¬ 
tory file. Then the Back button scripts in the 
regular database files can be as few and as 


Select a date for viewing teems 
11/1/96 



Print Found Slips 


Find & Print Slips 


Figure la 



Figure b 


simple as possible. 

A Special Relation 

Access to the global history function is 
made through a special sort of FileMaker 3.0 
relation. Ordinarily, a relation allows a home 
key (the key field in the files using the Back 
button) to be a global field but requires that 
the foreign key (the key field in the global 
history control file) be an indexable field. 

This means the foreign key cannot be a global 
field or a calculation field based on a global or 
a related field. 

However, our case is a special one. We 
only want access to global fields in the global 
history control file (named Resources_ in 
our examples), which means we don’t need 
record-by-record access through a relation. If 
we create a global constant field of type text 
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Define Fields for "Resources. 


182 field(s) 


Field Name 


♦ GlobalConstant 


I'JEi 


O ptions 


View by [ field name ▼ 


A global field is defined to contain only one value which is shared across 
all records in a file. It can be used as a temporary storage location (as in 
scripts). 


* Gk 

* Gk 

* Gk 

* gM 

* gh' 

* gk' 

* gM 

* gM 

* gO 

* gP 

* gP j 

* gP 

* gP 

* gPf ii r ^ HU I YIP^-Hj p f‘2.G T Stili 


Options for Global Field “GlobalConstant” 


Data type: Text 


l] Repeating field with a maximum of 


repetitions 


[ Cancel ] 


Figure 2 

in every file, we can define a relation, Global- 
Resources, between any file and the Re- 
sources_ file and get access to all global fields 
in the Resources_ file. It is not necessary to 
enter any value in the GlobalConstant fields, 
although when used for other purposes they 
should all contain a value of “1”, or some 
other constant. 

Here’s the set up: 

1. Define the global constant field, 
GlobalConstant, in all files in the database; 

2. Define a relation between each file 
(except the global history file) and the global 

Figure 3 history file (Resources_); 


Once these rela¬ 
tions are set, notice 
that you have created 
a wheel and hub 
architecture. The 
global history file, 
Resources_, is the 
hub, the Global- 
Resources relations 
are the spokes, and 
the other files are on 
the rim of the wheel. 
It is now possible to 
write to or read from all global fields in 
Resources_ from any other file in the data¬ 
base. This makes various sorts of inter-file 
scripting, including our Back button, quick 
and easy to implement. Although FileMaker 
global fields are, strictly speaking, file globals, 
this arrangement produces, in effect, data¬ 
base globals — a universal scratch pad for 
storing and retrieving whatever is useful. 

| 

History Fields 

In Resources_, history information is 
stored and retrieved from four global fields: 
one field for the global history, one for the 

return-to layout, 
one for the return- 
to file, and one for 
the return-from file. 
This last field allows 
a test for whether 
the file needs to be 
changed or you are 
moving back within 
the same file by 
simply switching 
layouts. These are 
simple global text 
fields, no repeats. 


Edit Relationship 


Relationship Name 


GlobalResources 


A relationship defines a set of matching related records for 
each record in the current file. 


Match data from field in current file: 

Person 


With data from field in related file: 

Resources— 


I | When deleting a record in this file, also 
delete related records 


[ Specify File... ] 


FirstNameLastName 

|'1^ 


: :gButton Picture Three 

Friend 



: igButton Picture Two 

FriendExp 



::gButtonPix 

gAddressType 

nr 


::gCompany Logo 

gContactTypeSelect 

p 


::gDateRangeString 

gDonationsQuery Year 

;5j: 


::GHBackOrigin 

Gender 



: :GHhistory 

gFile Key 



::GHlastFile 

gGoToRecord 

liii 


::GHlastLayout 


H; 






j | Allow creation of related records 

[ Cancel ) 



The FileMaker Report • ©1997 Watertechnics • Issue 68 • Page 11 




































The Scripts 

The real work of 
the back button is 
done through inter¬ 
file scripting. Every 
file in the database, 
including the Resources_ file, needs three 
scripts: one to update the global history, one 
to initiate a go-back, and one to receive a go- 
back. These are identical in each file except 
for the Resources_ file scripts. 

When moving forward, we want to record 
the current location before leaving. This is 
done by using the GoForward script step in 
each script involving a layout change, insert¬ 
ed just before the layout change step. (Not all 
movement should be recorded. This Back 
button scheme has a default that a movement 
is not recorded .) The GoForward script plac¬ 
es the file name and layout number, separat¬ 
ed by a comma, in the global history field 
(GHhistory) of the Resources_ file. Each of 
these entries is preceeded by a semicolon. 

Figure 5 shows a typical contents of the 
GHhistory field: four steps with text words as 
file names and numbers as layout numbers. 
This may be read as “started in file Esalen on 
layout 3, went next to layout 7 in the same file, 
then went to the Person file layout 39 fol¬ 
lowed by a move to layout 2 in the same file.” 

When you press a Back button, it acti¬ 
vates the GoBack script step in the Resources_ 
file. GoBack extracts the last file name and 
last layout number from the GHhistory field 
and places them in their corresponding global 
fields (GHLastFile and GHlast- 
layout), removing this informa¬ 
tion from the end of the global 
history stack (GHhistory). Go- 
Back then decides, based on the 
latest file global (GHlastfile), in 
which database file to activate the 
Return script — in effect decid¬ 


Define Fields for “Resources-” 


182 field(s) 


Field Name 

lye® 

Options 

View by custom order 

▼ 

♦ GHhistory 

Global 

Text 


IF 

♦ GHlastFile 

Global 

Text 


■Wf* 

* GHlastLayout 

Global 

Text 


m 






1 F ar'-ili+i i N amaPinhf 

rrift hai 

Tov+ 




ing in this way to which file to return. The 
Return script moves to the layout number 
specified in the Resources_ file global 
(GHlastlayout) and the “go back one step” 
action is complete. 

At first glance, this seems a clumsy way to 
navigate. However, thanks to the smoothness 
with which FileMaker handles cross-file 
scripting, the process is quick and transparent. 
Each database file needs three scripts: 

Go Forward 

- Set field [Resources_::globalHistory] 
Resources_::globalHistory & 

& Status (CurrentFileName) & 

& Status(CurrentLayoutNumber) 

Go Back 

- Enter Browse Mode 

- Set Field [Resources_::GHbackOrigin] 

Status (currentFileName) 

- Perform Script [subscripts. External: 

"Resources_","GoBack") 

- Exit Script 

Return 

- Enter Browse Mode 

- Go to Layout ["Resources_::GHIastLayout"] 

- If (Status (currentFileName) = 

Resources_::GHbackOrigin) 


Figure 4 


Figure 5 
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Figure 6 




Available Steps 

"GHReturn * 

Control 

o 

* If ["GHIastFile = "Starter""] 


Perform Script 

mmm 

* Perform Script [Sub-scripts, External: "Starter (*)"] 


Pause/Resume Script 


♦ Exit Script 

1 ~~ 

Exit Script 


* End If 


Halt Script 


* If ["GHIastFile = “Rez Page" "] 


If 


* Perform Script [Sub-scripts, External: "Rez Page "] 


Else 


* Exit Script 


End If 


* End If 


Loop 


* If ["GHIastFile = "Contact""] 


Exit Loop If 


* Perform Script [Sub-scripts, External: "Contact"] 


End Loop 


* Exit Script 


Allow User Abort 


* End If 


Set Error Capture 


♦ If ["GHIastFile = "Information”"] 


Navigation 


* Perform Script [Sub-scripts, External: " Information "] 


Go to Layout 


* Exit Script 


Go to Record/Request/Page 


* End If 

$ 

Go to Related Record 

Go to Portal Row 


<M Mil | < 

J 


±. r:.ij 


Exit script 

- End If 

- Halt Script 

Resources_ Control Scripts 

The Resources_ file needs the same three 
scripts as the database files, with a few alter¬ 
ations. 

GoForward 

- SetField [GHglobalHistory] globalHistory 

& & Status (CurrentFileName) & 

& Status (CurrentLayoutNumber) 

Go Back 

- Enter Browse Mode 

- SetField [GHIastLayout] Right(GHhistory, 

Length(GHhistory) - Position(GHhistory,",",1, 
PatternCount(GHhistory,","))) 

- SetField [GHIastFile] Middle(GHhistory, 

Position(GHhistory,";", 1, 
PatternCount(GHhistory,";"))+1, 
Position(GHhistory,1, 
PatternCount(GHhistory, 
Position(GHhistory,";", 1, 
PatternCount(GHhistory, ) 

- SetField [GHhistory] 

Left(GHhistory,Position(GHhistory,1, 
PatternCount(GHhistory, ) 

- Perform Script [subscripts. Return] 


Return 

-If [GHIastFile = "filer] 

Perform Script [subscripts. 

External: "filel", "Return"] 

- End If 

- Exit Script 

Include in the Resources^ Return script 
the four “Return” steps for every other file 
(exclude Resources_) in the database. See 
Figure 6. 

Implementation 

Place the GoForward script in any script 
that moves to another layout, if you want the 
option to return to the current layout. Create 
a Back button and connect it to the GoBack 
script. Place this button on any layout that 
warrants this type of escape. Remember that 
you may not always want to record the cur¬ 
rent layout when moving to another one. An 
example is when you perform a search with a 
dedicated search screen. If you back away 
from the search results screen, you may not 
want to see the search request screen. In this 
case, omit the GoForward script from the 
search script. In the following example, as¬ 
sume you are looking at an invoice in the 
Invoice file and you want to go to the Line- 
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Items file: 

GoToLineltems 

- Enter Browse Mode 

- Perform Script [subscripts, "GoForward"] 

- Perform Script [subscripts, "External", 

"Lineltems","GoLayoutList"] 

This script records the current layout in 
the Invoice file then calls a script in the Line- 
Items file which changes to the list layout. By 
activating the GoBack script in the Lineltems 
file, you can return to the Invoice file in the 
layout where you left off. You may want to go 
to the Lineltems file from several different 
places, so just include the GoForward script 
in each of the appropriate navigation scripts. 

There are some script management issues 
that arise from the added complexity of global 
history implementation. Remember when 
creating scripts for a complex database to use 
many small component scripts rather than a 
few large do-it-all-at-once scripts. I discov¬ 
ered early on that even basic local navigation 
scripts (scripts that simply go to layouts in 
the local file) become more useful and reus¬ 
able when split into two. One script calls 
GoForward and then calls the second script 
which does the actual layout change. This 
way you can call the second script to get a 
navigation step without creating unwanted 
layout recordings. If you follow this protocol, 
you end up with two scripts each for most of 
your active layouts. 

ScriptOne 

- Enter Browse Mode 

- Perform Script [subscripts, "GoForward"] 

- Perform Script [subscripts, "ScriptTwo"] 

ScriptTwo 

- Enter Browse Mode 

-GoTo Layout ["DataEntry”] 


While moving around within a file, you 
usually use ScriptOne. For moving between 
files, create a script like the GoToLineltems 
script above. In the Perform External Script 
step, call the external ScriptTwo. If you call 
ScriptOne as an external script, you get an 
unwanted layout recording. With a little 
experience, maintaining Back buttons in all 
your files becomes second nature. 

Enhancements 

This basic global history scheme can be 
expanded to include recording and retrieving 
the found set, current record, user ID, and 
other information. This allows features like 
reinstating all the conditions of an interrupt¬ 
ed work session. In a small way, the Back 
button illustrates some of the changes to the 
FileMaker development environment occa¬ 
sioned by version 3.0. New 3.0 features pro¬ 
vide a much more powerful development 
environment, an environment in which user 
simplicity can be purchased at the price of 
more design effort and discipline on the part 
of the database author. In the beginning, this 
means a serious investment in more thought¬ 
ful and systematic software housekeeping. 
After some facility is gained, the payoff be¬ 
comes better results with less development 
effort. 
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News & Notes 


Claris Solutions Conference 

Claris is sponsoring a Solutions Confer¬ 
ence for developers who are using Claris 
software. Dates: May 12-15, 1997. Location: 

San Jose Fairmont Hotel, San Jose, Califor¬ 
nia. For information call Unconventional 
Promotions at 415-566-4544 or e-mail to 
shows@unconventional.com. Detailed infor¬ 
mation also available on the internet at 
www. claris. com/solutionsconference. 

FileMaker Bowl j 

Claris has accepted an offer from the 
DIG.FM user group to sponsor a FileMaker 
team competition on Wednesday evening of 
the May CSA Conference (above). The “Col- f 

lege Bowl” format pits teams of four against 
each other, in groups of three teams. Ques¬ 
tions will cover FileMaker in these categories: 

• History • Trivia • Audience Questions • Fea¬ 
tures • Practical • Matching Survey Responses 

• Technical • Multiple Choice • Etc. 

DIG.FM is now accepting applications 
for teams who would like to be part of the 
competition. A variety of team affiliations are 
possible: geographic, national, organization, j 
or other. Individuals and small groups who 
would like to participate through teams 
formed during the conference are also invited. 

Teams will be presented with a problem 
or question simultaneously. Each team mem¬ 
ber will have a button and the first person to 
press the button gets a chance to answer the 
question. Answers are by the team as a whole, I 
so time is allowed for conferring among team 
members. Points will be awarded for correct 
answers and subtracted for wrong answers. 
Ambiguous answers will be handled by a 
team of three judges. If the first answer is wrong 
the second team to respond gets a chance, 


then the third if the second team is wrong. 
Presentation of a question is halted as soon as 
a contestant hits a button. There maybe some 
eliminations before the Wednesday “finals”. 

The FileMaker Bowl has the potential to 
become a regular, entertaining, and lively 
institution for the FileMaker community. 
DIG.FM will work to make the event fun for 
everyone. While we expect a reasonably seri¬ 
ous level of competition, no one should as¬ 
sume that they will be overwhelmed by tough 
teams. The variety of questions will keep 
things reasonably balanced among various 
kinds of FileMaker professionals and ama¬ 
teurs involved in different aspects of File¬ 
Maker development, use, and consulting. 

The most effective teams will be composed of 
members with a variety of backgrounds and 
expertise. 

Priority will be given to teams who sign 
up early. Teams need not specify their entire 
line-up but please give us as much informa¬ 
tion as you can, including a bit about the 
background of members and the team as a 
whole. 

So sign up! If you can’t sign up, plan to 
attend and enjoy the fun. To submit ques¬ 
tions for the contest (please do!) download 
our Quiz Questions template from www. 
digfm.org. 

Contacts: 

Mike Harris 
DIG.FM Chair 
FMannex@aol.com 
PO Box 2307 

Santa Cruz CA 95063-2307 
408-430-9060 

Bill Richardson 
BillR@sirius. com 
415-564-2881 

—V* 
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